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Abstract 

This paper connects the definitional interpreter for the A-calculus 
extended with delimited continuation constructs, shift and reset, 
with a compiler and a low-level virtual machine that copies a 
part of a data stack to implement delimited continuations. Follow- 
ing the functional derivation approach proposed and popularized 
by Danvy, we interrelate the two implementations via a series of 
meaning-preserving program transformations whose validity is in- 
dependently known. As a result, this work formally establishes the 
correctness of a compiler and a low-level stack-copying implemen- 
tation of delimited continuations. In particular, the resulting virtual 
machine properly models when to store return addresses into a data 
stack and which part of a data stack to copy. To our knowledge, this 
work is the first to prove correctness of such low-level features of 
delimited continuations. It also shows that the functional derivation 
approach is equally applicable to establish correctness of low-level 
implementations . 

Categories and Subject Descriptors D.1.1 [Programming Tech- 
niques]: Applicative (Functional) Programming; D.3.3 [Program- 
ming Languages]: Language Constructs and Features — Control 
structures; D.3.4 [Programming Languages ]: Processors — Com- 
pilers, Interpreters; F.3.3 [Logics and Meanings of Programs]: 
Studies of Program Constructs — Control primitives; F.4.1 [Math- 
ematical Logic and Formal Languages]: Mathematical Logic — 
Lambda calculus and related systems; 1.2.2 [Artificial Intelli- 
gence]: Automatic Programming — Program transformation 

General Terms Languages, Theory 

Keywords Functional Derivation, Delimited Continuation, Vir- 
tual Machine, Defunctionalization, CPS Transformation 

1. Introduction 

First-class continuations play an important role in controlling flow 
of execution in a flexible manner without converting a program into 
continuation-passing style (CPS). In particular, delimited continu- 
ations [9] find many applications due to its clear semantics through 
CPS transformation, such as non-deterministic programming [9], 
typed printf [4], dynamic code generation [16], and let-insertion in 
partial evaluation [3, 19, 26]. 
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Background and related work As delimited continuations be- 
come used in many places, various direct implementations of de- 
limited continuations are proposed that copy a part of a data stack. 
Gasbichler and Sperber [13] implemented delimited continuations 
via stack copying on Scheme 48 bytecode. Masuko and Asai [20] 
implemented delimited continuations at the PowerPC assembly 
level in the MinCaml compiler framework [25]. Kiselyov [17] de- 
scribes a general implementation method to introduce delimited 
continuations into a system equipped with stack overflow and ex- 
ceptions. 

However, the correctness of these approaches relies on informal 
arguments backed up with practical experience. As such, it is dif- 
ficult to discuss correctness of low-level implementations such as 
the one in an assembly language. Although Dybvig, Peyton Jones, 
and Sabry [12] showed operational and CPS semantics for delim- 
ited continuations and prove their equivalence, their formalization 
is still abstract and does not model, for example, return addresses, 
that are typically stored in a data stack and copied when continua- 
tions are captured. Recently, Rornpf, Maier, and Odersky [24] inte- 
grated delimited continuations into Scala. While remarkable, their 
implementation is not suitable for discussing low-level aspects such 
as stack copying, because delimited continuations are emulated as 
functions via type-directed, selective CPS transformation. 

Our approach To establish correctness of a low-level implemen- 
tation of delimited continuations, we employ the functional deriva- 
tion approach proposed and popularized by Danvy [2, 8]. Starting 
from the definitional interpreter for a language with delimited con- 
tinuation constructs, we apply a series of meaning-preserving pro- 
gram transformations whose validity is already known. Following 
Danvy, we use defunctionalization [23], refunctionalization [10], 
and CPS transformation [22], In addition, we introduce several 
other program transformations. 

The advantage of this approach is that the correctness of derived 
implementation follows directly from the correctness of program 
transformations. This is in contrast to the conventional approach 
where one had to prove, either by hand or using a proof assistant, 
that the original implementation and the derived implementation 
behave the same. Furthermore, since there are already various use- 
ful transformations, we can explore the design space of implemen- 
tations simply by trying one transformation after another. Thus, it is 
not only used by Danvy’s group to derive various virtual machines 
[1], but also used to derive a compiler and a virtual machine for a 
multi-stage language that supports backquote and unquote [14], 

Biernacka, Biernacki, and Danvy [6] use a functional corre- 
spondence to derive an abstract machine for A-calculus with multi- 
level delimited continuations. Danvy and Millikin [11] start from 
Landin’s SECD machine with the J operator [18] and derive a fam- 
ily of evaluation functions. However, both of the work deal with a 
high-level abstract machine that is based on a state transition sys- 
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tem rather than a low-level virtual machine that operates on instruc- 
tions. 

Contribution The contribution of this paper is to connect the 
definitional interpreter for the A-calculus extended with delimited 
continuation constructs, shift and reset, with a compiler and a 
low-level virtual machine that copies a part of a data stack to 
implement delimited continuations. As a result, this work formally 
establishes the correctness of a compiler and a low-level stack- 
copying implementation of delimited continuations. 

In the previous work [20], Masuko and the first author presented 
an invariant on a data stack when continuations are captured and 
invoked to implement delimited continuations. The virtual machine 
presented in this paper properly models it, in addition to when to 
store return addresses into a data stack and which part of a data 
stack to copy. To our knowledge, this work is the first to prove 
correctness of such low-level features of delimited continuations. 
It also shows that the functional derivation approach is equally 
applicable to establish correctness of low-level implementations. 

Prerequisites We assume basic familiarity with CPS transforma- 
tion [22] and defunctionalization [23]. When functions are trans- 
formed into CPS, all the calls become tail calls. Such functions can 
be regarded as an abstract machine where a state of the machine 
consists of the arguments of the functions. We will use this fact to 
derive a virtual machine for delimited continuations. 

Organization This paper is organized as follows. In Section 2, 
we introduce delimited continuation constructs, shift and reset, and 
show the definitional interpreter for them. In Section 3, we intro- 
duce a data stack into the definitional interpreter. It is decomposed 
into a compiler and a virtual machine in Section 4. The virtual 
machine is further transformed so that it manipulates a segmented 
stack in Section 5. The property of the obtained virtual machine is 
discussed in Section 6. The paper concludes in Section 7. 

2. Definitional Interpreter 

In this section, we introduce delimited continuation constructs, 
shift and reset, and show the definitional interpreter for them. 

2.1 Shift and Reset 

Danvy and Filinski [9] introduced two operators, shift and reset, for 
capturing the current continuation. As a concrete syntax, 

shift (fun k -> M) 

captures the current continuation up to the enclosing reset and binds 
it to k to be used in M. The captured continuation is removed from 
the current continuation: if it is not used in M, it is discarded. The 
context is delimited by reset: 

reset (fun () -> M) 

The shift operation executed in M captures the continuation only up 
to this reset expression. The exact semantics of shift and reset is 
defined in Section 2.3. 

For example, consider the following program: 

1 + reset (fun () -> 

2 + (shift (fun k -> 3 * k (k 4)))) 

The continuation captured by shift is up to the enclosing reset, 
namely 2 + [] , which is bound to k. Since the captured continu- 
ation is removed from the current continuation, the above program 
is reduced to: 

1 + reset (fun () -> 3 * (2 + (2+4))) 
and the result becomes 25. 

Capturing delimited continuations enables us to have control 
over the type of the context. Consider the following program: 


type t = Var of string (* term *) 

I Lam of string * t I App of t * t 
I Shift of string * t I Reset of t 

type xs = string list (* argument list *) 

(* offset : string -> xs -> int *) 
let offset x xs = 

let rec loop xs n = match xs with 
[] -> raise UnboundVariable 
I a: :rest -> 

if x = a then n else loop rest (n + 1) 
in loop xs 0 


Figure 0. Syntax of A-calculus with shift and reset and an auxiliary 
function offset 


reset (fun () -> 

shift (fun k -> fun x -> k x) * "world") 

"Hello " 

The type of the body of reset appears to be a string, because the 
result is a concatenation of something with "world". However, the 
shift operator captures the current continuation, [] ~ "world", 
binds it to k. and returns a function. Thus, the above program is 
reduced to: 

reset (fun () -> fun x -> x "world") 

"Hello " 

and then to: 

(fun x -> x "world") 

"Hello " 

to produce finally "Hello world". With this observation, one can 
implement typed printf using delimited continuations. Interested 
readers are invited to read the first author’s article [4] which comes 
with introduction to delimited continuations. 

2.2 Syntax 

Figure 0 shows the syntax of the input language we use in this 
paper. It is a standard A-calculus extended with shift and reset. The 
figure also shows an offset function that returns the position of 
a variable x in a variable list xs. The definition of offset is the 
same throughout this paper. 

2.3 Definitional Interpreter 

Figure 1 shows the definitional interpreter for the A-calculus with 
shift and reset [9]. It is a standard CPS interpreter extended with 
shift and reset. Shift captures the current continuation c, binds it 
to x. and resets the current continuation to empty (i.e., an iden- 
tity function). Reset delimits the continuation captured by shift by 
resetting the current continuation to empty and applies the contin- 
uation c of reset in direct style. 

An environment is represented as two lists, a list of names 
xs and a list of values vs, instead of more usual association list 
of pairs of names and values. Thus, a value bound to a variable 
is obtained by two functions, offset and List. nth. The latter 
function returns the n’th element of a given list, starting at index 
zero. The use of two lists makes it easy to decompose an interpreter 
into a compiler and a virtual machine. It is called a binding-time 
improvement [15, Chapter 12], a standard technique in the partial 
evaluation community. 

Starting from this interpreter, we derive its low-level implemen- 
tation via a series of program transformations. 
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(* value *) 


type v = VFun of (v -> c -> v) 

I VCont of c 

and c = v -> v (* continuation *) 

(* fl : t -> xs -> v list -> c -> v *) 
let rec fl t xs vs c = match t with 

Var(x) -> c (List. nth vs (offset x xs)) 

I Lam(x,t) -> 

c (VFun (fun v c’ -> 

fl t (x: :xs) (v: :vs) c’)) 

I App(tO,tl) -> 

fl tO xs vs (fun vO -> 
fl tl xs vs (fun vl -> 
match vO with 

VFun(f) -> f vl c 
I VCont (c’) -> c (c’ vl))) 

I Shift(x,t) -> 

fl t (x: :xs) (VCont (c) :: vs) (fun v -> v) 

I Reset (t) -> c (fl t xs vs (fun v -> v) ) 

(* evall : t -> v *) 

let evall t = fl t [] [] (fun v -> v) 


Figure 1. Definitional interpreter for A-calculus with shift and 
reset (evall) 

3. Stack Introduction 

In this section, we aim at introducing a data stack into the defi- 
nitional interpreter. Instead of returning a value, the resulting in- 
terpreter passes around a data stack and results of evaluation are 
pushed onto the data stack. We show that a data stack is systemati- 
cally introduced by splitting dynamic data hidden in a continuation 
chain. To be more concrete, we will modify the representation of 
a continuation c in the following way: defunctionalization (Sec- 
tion 3.1), linearization (Section 3.2), stack extraction (Section 3.3), 
delinearization (Section 3.4), and refunctionalization (Section 3.5). 
After defunctionalization and linearization, a data stack will be ex- 
tracted naturally from the type of continuations. Converting the rep- 
resentation of continuations back to the original higher-order func- 
tions, we will obtain a stack-based interpreter. 

3.1 Defunctionalization 

Figure 2 shows the result of defunctionalizing continuations. To de- 
functionalize continuations, we first assign a constructor for each 
continuation in a program. In Figure 1, there are three kinds of 
continuations: the identity function and two continuations in the 
App case. We assign them the constructors CO, CAppO, and CAppl. 
respectively, with the arguments being free variables of the corre- 
sponding continuations. See the definition of type c in Figure 2. 

We then replace application of a continuation with a call to a 
dispatch function (run_c2), which describes what to do when the 
continuation object is called. 

The equivalence of evall and eval2 follows from the correct- 
ness of defunctionalization [5, 21], 

3.2 Linearization 

Figure 3 shows the result of linearizing continuations. The defini- 
tion of type c in Figure 2 shows that a continuation consists of a 
sequence of CAppO or CAppl with CO at the end. Since it is isomor- 
phic to the structure of a list, a continuation can be equivalently 
represented as a list of frames, where a frame is either CAppO or 
CAppl without the c component. See the definition of types f and 
c in Figure 3. The functions run_c3, f3, and eval3 are accord- 
ingly modified. 


type v = VFun of (v -> c -> v) (* value *) 

I VCont of c 

and c = CO (* continuation *) 

I CAppO of t * xs * v list * c 
I CAppl of v * c 

(* run_c2 : c -> v -> v *) 
let rec run_c2 c v = match c with 
CO -> v 

I CAppO (tl ,xs , vs , c) -> f2 tl xs vs (CAppl(v,c)) 

I CAppl (vO,c) -> 

(match vO with 

VFun(f) -> f v c 

I VCont (c’) -> run_c2 c (run_c2 c’ v)) 

(* f2 : t -> xs -> v list -> c -> v *) 
and f2 t xs vs c = match t with 

Var(x) -> run_c2 c (List. nth vs (offset x xs)) 
I Lam(x,t) -> 

run_c2 c (VFun(fun v c ’ -> 

f2 t (x::xs) (v: :vs) c’)) 

I App(tO,tl) -> f2 tO xs vs (CAppO(tl ,xs , vs , c) ) 

I Shift(x,t) -> f2 t (x: :xs) (VCont (c) :: vs) CO 
I Reset (t) -> run_c2 c (f2 t xs vs CO) 

(* eval2 : t -> v *) 

let eval2 t = f2 t [] [] CO 


Figure 2. Defunctionalized interpreter (eval2) 


type v = VFun of (v -> c -> v) (* value *) 

I VCont of c 

and f = CAppO of t * xs * v list (* frame *) 

I CAppl of v 

and c = f list (* continuation *) 

(* run_c3 : c -> v -> v *) 
let rec run_c3 c v = match c with 
□ -> v 

I CAppO (tl ,xs , vs) :: c -> 

f3 tl xs vs (CAppl (v) :: c) 

I CAppl (vO) : : c -> 

(match vO with 

VFun(f) -> f v c 

I VCont (c’) -> run_c3 c (run_c3 c’ v) ) 

(* f3 : t -> xs -> v list -> c -> v *) 
and f3 t xs vs c = match t with 

Var(x) -> run_c3 c (List. nth vs (offset x xs)) 
I Lam(x,t) -> 

run_c3 c (VFun(fun v c ’ -> 

f3 t (x: :xs) (v: :vs) c’)) 

I App(tO,tl) -> f3 tO xs vs (CAppO(tl ,xs , vs) : : c) 
I Shift(x,t) -> f3 t (x: :xs) (VCont (c) :: vs) [] 

I Reset (t) -> run_c3 c (f3 t xs vs []) 

(* eval3 : t -> v *) 

let eval3 t = f3 t [] [] [] 


Figure 3. Linearized interpreter (eva!3) 
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(* value *) 


type v = VFun of (v -> s -> c -> v) (* value *) 
I VCont of c * s 
I VEnv of v list 

and f = CAppO of t * xs (* frame *) 

I CAppl 

and c = f list (* continuation *) 

and s = v list (* data stack *) 

(* run_c4 : c -> v -> s -> v *) 
let rec run_c4 c v s = match (c, s) with 
( □ , □ ) -> v 

I (CAppO(tl ,xs) : : c , VEnv(vs)::s) -> 
f4 tl xs vs (v::s) (CAppl: :c) 

I (CAppl: :c, vO::s) -> 

(match vO with 

VFun(f) -> f v s c 
I VCont (c ’ , s ’ ) -> 

run_c4 c (run_c4 c’ v s’) s) 

(* f4 : t -> xs -> v list -> s -> c -> v *) 
and f4 t xs vs s c = match t with 
Var(x) -> 

run_c4 c (List. nth vs (offset x xs)) s 
I Lam(x,t) -> 
run_c4 c 

(VFun (fun vs’ c’ -> 

f4 t (x: :xs) (v::vs) s’ c’)) 
s 

I App(tO,tl) -> 

f4 tO xs vs (VEnv(vs) : : s) (CAppO (tl ,xs) :: c) 

I Shift (x,t) -> 

f4 t (x: :xs) (VCont (c , s) :: vs) [] [] 

I Reset (t) -> run_c4 c (f4 t xs vs [] [] ) s 

(* eval4 : t -> v *) 

let eva!4 t = f4 t [] [] [] [] 


Figure 4. Stack-based interpreter (eval4) 


This local transformation is obviously correct. Thus. eval2 and 
eval3 are equivalent. 

3.3 Stack Extraction 

Examining the types f and c in Figure 3, we notice that the con- 
structors CAppO and CAppl contain both static (compile-time) data 
and dynamic (runtime) data. The term t and the variable list xs are 
compile-time data: they are fixed once the input program is given. 
On the other hand, the value list v list and the value v are run- 
time data: they are available only at runtime. Since our goal is to 
turn an interpreter into a compiler and a virtual machine, we sepa- 
rate a continuation into two parts. The static part of a continuation 
will eventually become a list of instructions. (See Section 5.3.) The 
dynamic part of a continuation becomes a data stack. This separa- 
tion is also a binding-time improvement. 

Typewise, the separation is done as follows. The type c in 
Figure 3 is defined as f list. We split the definition of f into a pair 
of new f and v. where the new f contains only the static part of the 
old f and the dynamic part is compensated by the accompanying v. 
Because the dynamic part of CAppO has type v list rather than v, 
we introduce a new constructor VEnv in v to hold a list of values. 

Now. a continuation is represented as a value of type (f * 
v) list. We further split it into two separate lists: f list * v 
list. The former is a (new) continuation (or a control stack) and 
the latter a data stack. See Figure 4. Because of this modification. 


type v = VFun of (v -> s -> c -> v) 

I VCont of c * s 
I VEnv of v list 
and c = CO (* continuation *) 

I CAppO of t * xs * c 
I CAppl of c 

and s = v list (* data stack *) 

(* run_c5 : c -> v -> s -> v *) 
let rec run_c5 c v s = match (c, s) with 
(CO, []) -> v 

I (CAppO(tl ,xs , c) , VEnv(vs)::s) -> 
f5 tl xs vs (v::s) (CAppl(c)) 

I (CAppl (c), vO::s) -> 

(match vO with 

VFun(f) -> f v s c 
I VCont (c’ , s ’ ) -> 

run_c5 c (run_c5 c’ v s’) s) 

(* f5 : t -> xs -> v list -> s -> c -> v *) 
and f5 t xs vs s c = match t with 
Var(x) -> 

run_c5 c (List. nth vs (offset x xs)) s 
I Lam(x,t) -> 
run_c5 c 

(VFun (fun vs’ c’ -> 

f5 t (x: :xs) (v: :vs) s’ c’)) 
s 

I App(tO,tl) -> 

f5 tO xs vs (VEnv(vs) : : s) (CAppO(tl ,xs , c) ) 

I Shift(x,t) -> 

f5 t (x::xs) (VCont (c , s) :: vs) [] CO 
I Reset (t) -> run_c5 c (f5 t xs vs [] CO) s 

(* eval5 : t -> v *) 

let eval5 t = f5 t [] [] [] CO 


Figure 5. Delinearized interpreter (eval5) 


VCont receives s in addition to c. The same for VFun: it receives s 
in addition to c. 

The changes in types suggest how to rewrite the interpreter: a 
continuation and a data stack are always passed around together; 
whenever a frame is pushed onto a continuation, the corresponding 
value is pushed onto a data stack; and whenever a frame is popped 
from a continuation, the corresponding value is popped from a 
data stack. Because of this exact correspondence, the length of the 
continuation and the data stack are always the same. 

Since this transformation simply changes the representation of 
continuations locally, we immediately see that the transformation 
is correct, i.e., eval3 and eval4 are equivalent. 

This transformation is the essence of stack introduction: a data 
stack is a dynamic counterpart of a continuation. We can actually 
observe that the intermediate results and live variables are stored 
in a data stack. However, we will defer this discussion until Sec- 
tion 3.5, where the interpreter is transformed back to more readable 
higher-order one. 

3.4 Delinearization 

The purpose of defunctionalization (Section 3.1) and linearization 
(Section 3.2) of continuations was to introduce a data stack. Now 
that we have successfully introduced a data stack, we apply the 
reverse transformation to the representation of continuations. This 
will result in a readable stack-based interpreter. Here, we change 
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(* value *) 


type v = VFun of (v -> s -> c -> v) (* value *) 

I VCont of c * s 
I VEnv of v list 

and c = v -> s -> v (* continuation *) 

and s = v list (* data stack *) 

(* f6 : t -> xs -> v list -> s -> c -> v *) 
let rec f6 t xs vs s c = match t with 

Var(x) -> c (List. nth vs (offset x xs)) s 
I Lam(x,t) -> 

c (VFun (fun vs’ c’ -> 

f6 t (x: :xs) (v: :vs) s’ c’)) 
s 

I App(tO,tl) -> 

f6 tO xs vs (VEnv(vs) : : s) 

(fun vO (VEnv(vs) : : s) -> 
f6 tl xs vs (vO::s) (fun vl (vO::s) -> 
match vO with 

VFun(f) -> f vl s c 
I VCont (c’,s’) -> c (c’ vl s’) s)) 

I Shift (x,t) -> 

f6 t (x: :xs) (VCont (c , s) :: vs) [] 

(fun v [] -> v) 

I Reset (t) -> 

c (f6 t xs vs [] (fun v [] -> v) ) s 
(* eval6 : t -> v *) 

let eva!6 t = f6 t [] [] [] (fun v [] -> v) 


Figure 6. Refunctionalized interpreter (eva!6) 


the representation of continuations from a list back to a defunction- 
alized form. 

Figure 5 shows the result. Notice that we delinearize only con- 
tinuations, not a data stack. As in Section 3.2, the equivalence of 
eval4 and eval5 follows from the isomorphism between a list of 
frames and c in Figure 5. 

3.5 Refunctionalization 

Finally, Figure 6 shows the result of refunctionalizing continua- 
tions. Refunctionalization [10] is the left inverse of defunctional- 
ization. Constructors in a defunctionalized form are transformed 
into higher-order functions. If refunctionalization succeeds, its cor- 
rectness follows from the correctness of defunctionalization. Thus, 
we conclude that eval5 and eval6 are equivalent. 

What have we obtained? Compared to the definitional inter- 
preter in Figure 1 , the interpreter in Figure 6 receives and returns a 
data stack as an additional argument. In particular, a continuation 
c receives a result value v and a data stack s. We can regard it as 
pushing v on s and passing v : : s as a whole to c. (We will actually 
do so in the next section.) 

Thus, the function f6 implements a standard stack-based inter- 
preter: the value of a variable and a function is pushed onto a data 
stack; the value of an application is computed by evaluating the 
function part tO, pushing the result vO on a data stack, evaluating 
the argument part 1 1 . pushing the result v 1 on a data stack, and then 
calling vO with the argument vl pushed on a data stack. The called 
function extracts the argument from the data stack and continues. In 
other words, we have successfully interrelated the stack-based in- 
terpreter and the standard interpreter via a series of program trans- 
formations. 

In addition, f 6 models saving and restoring of live variables vs. 
Before the function part tO is evaluated, vs is saved in a data stack. 


type v = VFun of (s -> c -> v) 

I VCont of c * s 
I VEnv of v list 
and c = s -> v (* continuation *) 

and s = v list (* data stack *) 

(* f7 : t -> xs -> s -> c -> v *) 
let rec f7 t xs (VEnv(vs) : : s) c = match t with 
Var(x) -> c ((List. nth vs (offset x xs))::s) 

I Lam(x,t) -> 

c (VFun(fun (v::s’) c’ -> 

f7 t (x: :xs) (VEnv(v: : vs) : : s ’ ) c’) 

: : s) 

I App(t0,tl) -> 

f7 tO xs (VEnv(vs) : : VEnv(vs) : : s) 

(fun (vO : : VEnv(vs) : : s) -> 
f7 tl xs (VEnv(vs) : : vO : : s) 

(fun (vl::v0::s) -> 

match vO with 

VFun(f) -> f (vl::s) c 
I VCont(c’,s’) -> c ((c’ (vl : : s ’ ) ) : : s) ) ) 

I Shift(x,t) -> 

f7 t (x::xs) [VEnv (VCont (c , s) :: vs)] 

(fun [v] -> v) 

I Reset (t) -> 

c ((f7 t xs [VEnv(vs)] (fun [v] -> v))::s) 

(* eval7 : t -> v *) 

let eval7 t = f7 t [] [VEnv([])] (fun [v] -> v) 


Figure 7. Interpreter with combined arguments (eva!7) 


It is restored back from the data stack after the evaluation of tO, 
when the evaluation of 1 1 requires it. 

The use of program transformations to derive a stack-based in- 
terpreter is particularly effective when an interpreter deals with un- 
familiar constructs, such as shift and reset, and it is not obvious 
how to write a stack-based interpreter for them. To capture a con- 
tinuation via shift, we see in Figure 6 that a captured continuation 
needs to hold not only a continuation but also a data stack (as in 
VCont (c,s)) and clear the current data stack. This behavior is 
consistent with a commonly-used implementation technique. Us- 
ing the functional derivation approach, we can certify that such an 
implementation method is correct. 

4. Extracting Virtual Machine 

In this section, we decompose the stack-based interpreter into a 
compiler and a virtual machine. The key transformation is factor- 
ization of combinators that control the dynamic behavior of pro- 
grams as virtual machine instructions. To do so, we first need to 
move inherited arguments to a data stack. 

4.1 Combining Arguments 

In the definitional interpreter (Figure 1), the argument vs is dis- 
tributed (or inherited) to all the recursive calls. In particular, it be- 
comes a free variable of the second continuation of App case. This 
prevented us from storing vs into a data stack and forced us to pass 
vs as a separate argument: even if we store vs in a data stack, there 
was no guarantee that it could be safely extracted when evaluation 
of 1 1 needed it. 

After defunctionalization and stack extraction, however, we dis- 
cover that vs can actually be stored in a data stack. Since vs is not 
a free variable of any recursive calls any more (except for the one 
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(* value *) 


in Lam case 1 ), we can move vs to the stack top. The result is shown 
in Figure 7. In the figure, we also moved the first argument of con- 
tinuations and functions in VFun into a data stack as mentioned in 
Section 3.5. 

This local transformation simply combines two arguments into 
one, and thus we can immediately conclude that eval6 and eval7 
are equivalent. 

4.2 Factoring Combinators as Instructions 

We now want to decompose the interpreter in Figure 7 into a com- 
piler and a virtual machine. A compiler accepts a static program 
text (i.e., t and xs) and produces a list of instructions. A virtual 
machine receives a list of instructions and executes it. Such de- 
composition can be done by first moving dynamic arguments to all 
branches and then factoring dynamic parts out as instructions. 

To be more concrete, the data stack and continuation arguments 
of the interpreter f 7 in Figure 7 are moved to each branch of the 
case dispatch on t as follows: 

let rec f7 t xs = match t with 

Var(x) -> fun (VEnv(vs) : : s) c -> ... 

I Lam(x,t) -> fun (VEnv(vs) : : s) c -> ... 

I App(tO,tl) -> fun (VEnv(vs) : : s) c -> ... 

I Shift(x,t) -> fun (VEnv(vs) : : s) c -> ... 

I Reset(x,t) -> fun (VEnv(vs) : : s) c -> ... 

Because we have eliminated an inherited argument, each fun 
(VEnv(vs) : : s) c -> ... does not have any free variables, i.e., 
it is a combinator. If this combinator is close enough to a machine 
instruction, we can think of f 7 t xs as compiling a term into an 
instruction. 

This is immediately true for Var case. Let us define an instruc- 
tion access as follows: 

let access n = fun (VEnv(vs) : : s) c -> 
c ((List. nth vs n)::s) 

This combinator is basic enough to treat as an instruction: it takes 
the n’th element of a vector vs, starting at index zero. Thus, the 
Var case of f 7 can be written as follows: 

Var(x) -> access (offset x xs) 

Note that we perform offset x xs at compile time. Because 
we know the position of x in xs at compile time, we embed the 
resulting number as an argument to access instruction. 

For other cases, it is not so straightforward, but once we realize 
that we can define an infix function composition operator (») in 
CPS, we can use it to encode a more complex expression in an 
instruction-like manner. For the App case, for example, we see that 
VEnv(vs) is pushed onto the data stack at the first recursive call 
(f7 tO xs). Thus, we can introduce a push_env instruction to 
accommodate this change of the data stack. The other cases are 
similar. The result is shown in Figure 8. 

The function f8 in Figure 8 looks like a compiler: given t and 
xs, f 8 recurs over the structure of t and returns instructions. In fact, 
if we defunctionalize instructions (we will do so in Section 5.2), f 8 
actually becomes a compiler and the dispatch function becomes 
a virtual machine. Before doing it. however, let us make some 
observations. 

First, some instructions receive arbitrarily long instructions as 
an argument. For example, push_closure receives the result of 
evaluating f8 t (x: :xs) (which can be very long) followed by 
return. Although it is not practical to provide long instructions as 
an argument to another instruction, this is not a problem, because 

1 For a function value, we need to copy vs to create a closure. See Sec- 
tion 5.4. 


type v = VFun of (s -> c -> v) 

I VCont of c * s 
I VEnv of v list 
I VK of c 

and c = s -> v (* continuation *) 

and s = v list (* data stack *) 

type i = s -> c -> v (* instruction *) 

(* (») : i -> i -> i *) 
let (>>) il i2 = fun s c -> 
il s (fun s’ -> i2 s’ c) 

(* access : int -> i *) 
let access n = fun (VEnv(vs) : : s) c -> 
c ((List. nth vs n)::s) 

(* push_closure : i -> i *) 

let push_closure code = fun (VEnv(vs) : : s) c -> 
c (VFun(fun (v::s ! ) c’ -> 

code (VEnv(v : : vs) : : s ’ ) c’) 

: : s) 

(* return : i *) 

let return = fun (v : : VK(c ’ ) : : s) _ -> 
c ’ (v: : s) 

(* push_env : i *) 

let push_env = fun (VEnv(vs) : : s) c -> 
c (VEnv (vs) : : VEnv (vs) : : s) 

(* pop_env : i *) 

let pop_env = fun (vO: : VEnv(vs) : : s) c -> 
c (VEnv (vs) : : vO : : s) 

(* call : i *) 

let call = fun (vl::vO::s) c -> 

match vO with (* dummy *) 

VFun(f) -> f (vl : : VK(c) : : s) (fun [v] -> v) 

I VCont (c’, s’) -> c ((c’ (vl : : s ’ ) ) : : s) 

(* shift : i -> i *) 

let shift code = fun (VEnv(vs) : : s) c -> 

code [VEnv (VCont (c , s) : :vs)] (fun [v] -> v) 

(* reset : i -> i *) 

let reset code = fun (VEnv(vs) : : s) c -> 
c ((code [VEnv(vs)] (fun [v] -> v))::s) 

(* f8 : t -> xs -> i *) 

let rec f8 t xs = match t with 

Var(x) -> access (offset x xs) 

I Lam(x,t) -> 

push_closure (f8 t (x: :xs) >> return) 

I App(tO,tl) -> 

push_env >> f8 tO xs » pop_env >> f8 tl xs 
» call 

I Shift(x,t) -> shift (f8 t (x::xs)) 

I Reset (t) -> reset (f8 t xs) 

(* eval8 : t -> v *) 

let eval8 t = f8 t [] [VEnv([])] (fun [v] -> v) 


Figure 8. Interpreter using combinators factored as instructions 
(eval8) 
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(* value *) 


type v = VFun of (s -> c -> d -> v) 

I VCont of c * s 
I VEnv of v list 
I VK of c 

and c = s -> d -> v (* continuation *) 
and d = v -> v (* dump (metacontinuation) *) 
and s = v list (* data stack *) 

type i = s -> c -> d -> v (* instruction *) 


Figure 9. 2CPS interpreter (eval9), type part 

we can store the result of compilation f 8 t (x : : xs) » return 
somewhere in the memory, and give a pointer to the first instruction 
as an argument to push_closure. 

Secondly, the output of the compilation is not a list of instruc- 
tions but a tree of instructions. This is again not a problem, because 
the operator (») is associative. We can always safely expand a 
tree of instructions into a list of instructions. 

Thirdly, Figure 8 is written in such a way that a return address 
(c) is stored in a data stack when a closure is called, rather than 
passing it as a continuation argument (see call instruction). For 
this purpose, a new constructor VK is introduced in type v. Because 
c is stored in a data stack, the continuation argument fun [v] -> 
v of f in call is a dummy continuation which will never be used. 
In return instruction, we see that the continuation argument is 
discarded and the continuation stored in a data stack is used. 

As this modification shows, there is no predefined instruction 
set that we have to use. We can define and introduce a new in- 
struction as we need it, so that the outcome best fits our intention. 
The functional derivation approach does not imply a mechanical 
process. Rather, it helps us to explore the design space of various 
implementation methods. 

Readers may doubt whether such modification is correct. The 
equivalence between eval7 and eval8 is established by first inlin- 
ing (») and all the instructions. The resulting interpreter is iden- 
tical to eval7 except for two places. The Lam case: 

c (VFun (fun (v: :VK(c’) : :s’) _ -> 

f7 t (x::xs) (VEnv(v: : vs) : : s ’ ) c’) 

: : s) 

and the last part of App case: 

match vO with (* dummy *) 

VFun(f) -> f (vl : : VK(c) : : s) (fun [v] -> v) 

I VCont (c’,s’) -> c ((c’ (vl : : s ’ ) ) : : s) 

Now, it is easy to see they are equivalent to eval7: the continuation 
argument is simply moved to the data stack. With this simple mod- 
ification, a standard calling convention of storing return addresses 
in a data stack is derivable. 

Finally, the reset instruction is rather unusual. It installs a new 
data stack [VEnv (vs)] and executes code with it. However, we 
usually use only one data stack. Rather than using multiple data 
stacks, we want to reuse a single data stack in a consistent way. 
This is the topic of the next section. 

5. Representing Dumps 

The obtained combinators in Figure 8 can be almost regarded as 
virtual machine instructions, because most of them simply pass on 
a data stack, modifying a top few frames if necessary. If we use the 
real machine stack instead of passing a data stack as an argument, 
the instructions do correspond to instructions in a stack machine. 

However, there are still a few exceptions. When a captured 
continuation VCont (c ’ , s ’ ) is applied in call: 


(* (») : i -> i -> i *) 
let (>>) il i2 = fun s c -> 
il s (fun s’ -> i2 s’ c) 

(* access : int -> i *) 
let access n = fun (VEnv(vs) : : s) c -> 
c ((List. nth vs n)::s) 

(* push_closure : i -> i *) 

let push_closure code = fun (VEnv(vs) : : s) c -> 
c (VFun(fun (v::s’) c’ -> 

code (VEnv(v : : vs) : : s ’ ) c’) 

: : s) 

(* return : i *) 

let return = fun (v : : VK(c ’ ) : : s) _ -> 
c ’ (v: : s) 

(* push_env : i *) 

let push_env = fun (VEnv(vs) : : s) c -> 
c (VEnv (vs) : : VEnv (vs) : : s) 

(* pop_env : i *) 

let pop_env = fun (vO: : VEnv(vs) : : s) c -> 
c (VEnv (vs) : : vO : : s) 

(* instructions same as Figure 8 up to here *) 

(* call : i *) 

let call = fun (vl::vO::s) c d -> match vO with 
VFun(f) -> (* dummy *) 

f (vl: :VK(c) : :s) (fun [v] d -> d v) d 
I VCont (c ’ , s ’ ) -> 

c’ (vl::s’) (fun v -> c (v::s) d) 

(* shift : i -> i *) 

let shift code = fun (VEnv(vs) : : s) c -> 

code [VEnv(VCont (c , s) : :vs)] (fun [v] d -> d v) 

(* reset : i -> i *) 

let reset code = fun (VEnv(vs) : : s) c d -> 
code [VEnv(vs)] (fun [v] d -> d v) 

(fun v -> c (v::s) d) 

(* f9 : t -> xs -> i *) 

let rec f9 t xs = match t with 

Var(x) -> access (offset x xs) 

I Lam(x,t) -> 

push_closure (f9 t (x::xs) >> return) 

I App(tO,tl) -> 

push_env >> f9 tO xs » pop_env >> f9 tl xs 
» call 

I Shift(x,t) -> shift (f9 t (x::xs)) 

I Reset (t) -> reset (f9 t xs) 

(* eval9 : t -> v *) 
let eval9 t = 

f9 t [] [VEnv([])] (fun [v] d -> d v) 

(fun v -> v) 


Figure 9. 2CPS interpreter (eval9), continued 
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type 

i = IAccess of int 

(* instruction 

*) 


1 IPush_closure of i I 

IReturn 



1 IPush_env I IPop_env 

1 ICall 



1 IShift of i | IReset 

of i 



1 ISeq of i * i 



type 

v = VFun of (s -> c -> d 

-> v) (* value 

*) 


1 VCont of c * s 




1 VEnv of v list 




1 VK of c 



and 

c = i list 

(* continuation 

*) 

and 

d = (c * s) list 

(* dump 

*) 

and 

s = v list 

(* data stack 

*) 


Figure 10. Interpreter with defunctionalized instructions 
(evallO), type part 

I VCont(c’,s’) -> c ((c’ (vl : : s ’ ) ) : : s) 

c ’ is applied to a saved data stack s ’ , which is different from the 
current data stack s. In reset, 

c ((code [VEnv(vs)] (fun [v] -> v))::s) 

code is executed on a newly created data stack [VEnv(vs)] which 
is again different from the current data stack s. Put differently, 
the interpreter in Figure 8 is not wholly written in CPS, because 
it contains non-tail calls to continuations. The goal of this section 
is to represent this direct-style information as a data structure. It 
turns out that the resulting data structure corresponds to a list of 
delimited data stacks. 

5.1 CPS Transformation 

To represent a direct-style application of continuations as a data 
structure, we transform this almost CPS interpreter into CPS one 
more time. The newly introduced continuations, or metacontinua- 
tions, correspond to dumps in the SECD machine [7, 18]. Figure 9 
shows the result of CPS-transforming Figure 8. 

Because eval8 was already written mostly in CPS, the second 
CPS transformation does not change functions very much except 
for their types. Although new functions receive a dump, it is usually 
^-reduced and does not appear in the function definition. A dump 
appears only in those instructions that explicitly modify it, namely, 
call, shift, and reset. 

The equivalence between eval8 and eval9 follows from the 
correctness of CPS transformation. 

5.2 Defunctionalization and Linearization 

To represent a dump as a data structure, we defunctionalize and 
linearize a dump and a continuation. At this moment, we defunc- 
tionalize instructions, too. Both the processes are mechanical. The 
result is shown in Figure 10. 

Through defunctionalization and linearization of a dump, the 
identity dump fun v -> v becomes an empty list. The dump fun 
v -> c (v::s) d in call and reset has three free variables c, 
s, and a dump d itself. After linearization, it becomes (c * s) 
list. 

Likewise, through defunctionalization and linearization of a 
continuation, the identity continuation fun [v] d -> d v be- 
comes an empty list. The continuation fun s’ -> i2 s’ c in 
(») has two free variables i2 and a continuation c itself. After 
linearization, it becomes a list of instructions. 

The dispatch function (run_ilO) for instructions is a virtual 
machine: given an instruction, it operates on a data stack and a 
dump. The defunctionalization of (>>) yields a sequence instruc- 
tion ISeq that connects two instructions into one. 


(* run_dl0 : d -> v -> v *) 
let rec run_dl0 d v = match d with 
□ -> v 

I (c,s)::d’ -> run_cl0 c (v::s) d’ 

(* run_cl0 : c -> s -> d -> v *) 
and run_cl0 c s d = match c with 

[] -> (match s with [v] -> run_dl0 d v) 

I g: :c -> run_il0 g s c d 

(* run_il0 : i -> s -> c -> d -> v *) 
and run_il0 i s c d = match i with 

IAccess(n) -> (match s with (VEnv(vs) : : s) -> 
run_cl0 c ((List. nth vs n)::s) d) 

I IPush_closure (code) -> 

(match s with (VEnv(vs) : : s) -> 
run_cl0 c 

(VFun(fun (v::s’) c’ d’ -> 

run_il0 code (VEnv(v: : vs) : : s ’ ) 
c ’ d’ ) 

: : s) d) 

I IReturn -> (match s with (v: :VK(c’) : :s) -> 
run_cl0 c’ (v::s) d) 

I IPush_env -> (match s with (VEnv(vs) : : s) -> 
run_cl0 c (VEnv(vs) : : VEnv(vs) : : s) d) 

I IPop_env -> (match s with (vO : : VEnv(vs) : : s) -> 
run_cl0 c (VEnv(vs) : : vO : : s) d) 

I ICall -> (match s with (vl::v0::s) -> 

match vO with (* dummy *) 

VFun(f) -> f (vl : : VK(c) : : s) [] d 
I VCont (c ’ , s ’ ) -> 

run_cl0 c’ (vl::s’) ((c,s)::d)) 

I IShift(code) -> (match s with (VEnv(vs) : : s) -> 
run_il0 code [VEnv (VCont (c , s) :: vs)] [] d) 

I IReset(code) -> (match s with (VEnv(vs) : : s) -> 
run_il0 code [VEnv(vs)] [] ((c,s)::d)) 

I ISeq(f,g) -> run_il0 f s (g::c) d 

(* (») : i -> i -> i *) 
let (>>) f g = ISeq(f,g) 

(* flO : t -> xs -> i *) 

let rec flO t xs = match t with 

Var(x) -> IAccess (of f set x xs) 

I Lam(x,t) -> 

IPush_closure (f 10 t (x: :xs) » IReturn) 

I App(t0,tl) -> 

IPush_env » flO tO xs » IPop_env 
» flO tl xs » ICall 
I Shift(x,t) -> IShift(flO t (x::xs)) 

I Reset (t) -> IReset(flO t xs) 

(* evallO : t -> v *) 
let evallO t = 

run_il0 (flO t [] ) [VEnv([])] [] [] 


Figure 10. Interpreter with defunctionalized instructions 
(evallO), continued 
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The equivalence between eval9 and evallO follows from the 
correctness of defunctionalization and the correctness argument for 
linearization we made in Section 3.2. 

In the obtained interpreter, all the instructions operate only 
on a data stack and a dump. They also receive a continuation as 
an argument, but looking at the dispatch function (run_clO), we 
notice that the only role of the continuation argument is to designate 
the next instruction. If we inline run_ilO into run_clO (as we will 
do in the next section), the continuation argument disappears. 

We can now regard s placed on top of d as a single system 
stack. This interpretation actually models the copy of a part of a 
data stack when a continuation is captured. We will discuss it in 
detail in Section 6. 

5.3 Code Flattening 

The instructions obtained so far are structured as a tree: the in- 
struction ISeq appends two trees of instructions. In this section, 
we transform it into a list of instructions. 

First, we observe (by unfolding run_clO) that the following 
two expressions are equivalent for any i, c, s. and d: 

run_clO (i : : c) s d 
run_ilO i s c d 

Thus, we can replace all the recursive calls in run_ilO (as well 
as the initial call to run_ilO in evallO) with calls to run_clO. 
With this replacement, we can inline run_ilO into run_clO so 
that run_clO dispatches over the first instruction of c. 

We then remove ISeq and replace it with an append operation ® 
on instructions, using a singleton list as a unit of instructions. The 
result is shown in Figure 11. The function fll now returns a list 
of instructions rather than a single instruction. In IPush_closure 
case of run_cll, code and c’ is appended, but because c’ is al- 
ways a dummy continuation [] , we do not actually have to manip- 
ulate code at runtime. In the next section, the dummy continuation 
disappears as the result of defunctionalization. 

The equivalence between evallO and evalll follows from 
the correctness of inlining and associativity of (»). Wand [27, 
28] used similar program transformation based on associativity of 
combinators. 

5.4 Defunctionalizing Function 

Finally, defunctionalization of functions in VFun yields a closure 
representation of functions. The type of VFun is changed to 

type v = VFun of c * v list (* value *) 

I ... 

Namely, a closure holds a code pointer and a list of values for its 
free variables. The only call site of this closure is in the ICall case. 
Corresponding modification to the virtual machine (run_cll) is 
simple: 

I IPush_closure (code) : : c -> 

(match s with (VEnv(vs) : : s) -> 
run_cll c (VFunCcode , vs) : : s) d) 

I ICall: :c -> (match s with (vl::vO::s) -> 
match vO with 

VFun(code , vs) -> 

run_cll code (VEnv(vl : : vs) : : VK(c) : : s) d 
I VCont (c ’ , s ’ ) -> 

run_cll c’ (vl::s’) ((c,s)::d)) 

The defunctionalized VFun constructed in the IPush_closure 
case is destructed in the ICall case. Rather than defining an apply 
function for VFun, it is inlined into the body of the ICall case. At 
that time, the dummy continuation [] is also inlined and reduced 
away. 


type i = IAccess of int (* instruction *) 

I IPush_closure of i list I IReturn 
I IPush_env I IPop_env I ICall 
I IShift of i list | IReset of i list 

type v = VFun of (s -> c -> d -> v) (* value *) 

I VCont of c * s 
I VEnv of v list 
I VK of c 

and c = i list (* continuation *) 

and d = (c * s) list (* dump *) 

and s = v list (* data stack *) 

(* run_dll : d -> v -> v *) 
let rec run_dll d v = match d with 
□ -> v 

I (c,s)::d’ -> run_cll c (v::s) d’ 

(* run_cll : i list -> s -> d -> v *) 
and run_cll c s d = match c with 

[] -> (match s with [v] -> run_dll d v) 

I IAccess (n) : : c -> 

(match s with (VEnv(vs) : : s) -> 

run_cll c ((List. nth vs n)::s) d) 

I IPush_closure (code) : : c -> 

(match s with (VEnv(vs) : : s) -> 
run_cll c 

(VFun(fun (v::s ! ) c’ d’ -> 

run_cll (codeOc’) (VEnv(v: : vs) : : s ’ ) d’) 
: : s) d) 

I IReturn: :c -> (match s with (v: : VK(c ’ ) : : s) -> 
run_cll c’ (v::s) d) 

I IPush_env::c -> (match s with (VEnv(vs) : : s) -> 
run_cll c (VEnv(vs) : : VEnv(vs) : : s) d) 

I IPop_env::c -> 

(match s with (vO : : VEnv(vs) : : s) -> 
run_cll c (VEnv(vs) : : vO : : s) d) 

I ICall: :c -> (match s with (vl::vO::s) -> 

match vO with (* dummy *) 

VFun(f) -> f (vl : : VK(c) : : s) [] d 
I VCont (c ’ , s ’ ) -> 

run_cll c’ (vl::s’) ((c,s)::d)) 

I IShift (code) :: c -> 

(match s with (VEnv(vs) : : s) -> 

run_cll code [VEnv(VCont (c , s) : : vs)] d) 

I IReset (code) :: c -> 

(match s with (VEnv(vs) : : s) -> 

run_cll code [VEnv(vs)] ((c,s)::d)) 

(* fll : t -> xs -> i list *) 
let rec fll t xs = match t with 

Var(x) -> [IAccess (offset x xs)] 

I Lam(x,t) -> 

[IPush_closure( (f 11 t (x : :xs) )@ [IReturn] )] 

I App(tO,tl) -> 

[IPush_env] @(f 11 tO xs)® [IPop_env] 
a(fll tl xs)® [ICall] 

I Shift(x,t) -> [IShift(fll t (x::xs))] 

I Reset(t) -> [IReset(fll t xs)] 

(* evalll : t -> v *) 

let evalll t = run_cll (fll t [] ) [VEnv([])] [] 


Figure 11. Interpreter with linear instructions (evalll) 
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C 


(c, [VEnv([|)J, []) 

(IAccess(n) :: c, VEnv(vs) 

: s,d) 

=> 

(c, (List .nth vs n) :: s, d) 

(iPush^losurelV) :: c, VEnv(ts) 

: s,d) 

=F 

(c, VFun(c', vs) :: s, d) 

(iReturn :: _,v :: VK(c) 

: s, d) 

=> 

(c, v :: s, d) 

(lPush_env :: c, VEn v(vs) 

: s,d ) 


(c, VEnv(us) :: VEnv(us) :: s,d) 

(lPop_env :: c, v :: VEnv(ts) 

: s,d) 

=F 

(c, VEnv(us) :: v :: s,d) 

(iCall :: c,v r :: VFun (c',vs) 

: s, d) 

=F 

(c' , VEnv(ui :: vs) :: VK (c) :: s, d) 

(iCall :: c,Vi :: VCont(c', s') 

: s,d) 

=F 

(c',v i :: s',(c,s) :: d) 

(IShif t(c') :: c, VEnv(ts) 

: s,d) 

=>■ 

(c', [VEnv(VCont(c, s) :: ts)],d) 

(iReset(c') :: c. VEnv(ts) 

: s,d ) 

=> 

(c' , [VEnv(vs)], (c, s) :: d) 

<u, 

H0> 

=F 

V 


) :: d) 

=> 

( c , v :: s, d) 


Figure 12. The obtained virtual machine 


This transformation is an instance of defunctionalization and is 
correct. 

6. Discussion 

Because all the calls in run_dll and run_cll are tail calls, they 
can be directly converted to a virtual machine. Figure 12 shows 
the final virtual machine we obtained in this paper, after inlining 
run_dll into run_cll. In addition to the standard calling conven- 
tion (i.e., saving and restoring return addresses and values of live 
variables), it precisely specifies the behavior of stack copying at 
continuation capture and invocation. When a context is delimited 
(see the behavior of IReset in Figure 12), the next instruction c (= 
the current continuation) and the current data stack s are pushed on 
a dump and the current data stack is cleared. When a continuation 
is captured (via IShif t), the next instruction c and the current data 
stack s are copied to the heap, the current data stack is cleared, and 
the body c' of shift is executed. When the captured continuation 
is invoked, the next instruction c and the current data stack s are 
pushed on a dump and the saved continuation and the data stack 
are restored. 

Figure 12 shows more than that. Remember that a dump d is 
a list of (c, s), and c is a code pointer (the return address for the 
evaluation of the current context). Thus, the top of a dump holds 
a return address. This validates the invariant we presented in the 
previous work [20] to implement delimited continuations: a return 
address and a reset pointer always reside immediately under the 
current data stack. 

Readers may think that copying a data stack s for every reset and 
continuation invocation is not realistic. This can be easily avoided, 
if we regard a data stack s and a dump d as a single stack. Assume 
that d has the form [(ci, si); . . . ; (c„, s n )]. If we know the length 
of each data stack s,, we can simply expand a data stack s and a 
dump d as a single stack: 

S@VK(ci)@Sl@ . . . @VK(Cn)@S n 

Then, resetting the current context amounts to simply pushing 
the current c (without copying s), and the continuation invocation 
amounts to copying the saved data stack s' (without copying s). The 
length of each data stack can be remembered by pushing a pointer 
to the end of the current data stack. Thus, the virtual machine even 
explains the need for a reset pointer! 

7. Conclusion 

In this paper, we have connected the definitional interpreter for 
the A-calculus with shift and reset with a compiler and a low-level 
stack-copying virtual machine. The obtained virtual machine ex- 
plains and certifies a number of implementation techniques for 
delimited continuations. The derivation process is not actually 


straightforward: we sometimes have to imagine the result of pro- 
gram transformation and what it means. However, the functional 
derivation approach surely provides us with the guidance as to 
which ways we can go and explore. Furthermore, connection via 
simple program transformation appears to suggest the meaning of 
various implementation techniques in a succinct way. 
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